The function of the TCP congestion control algorithm is to adjust the rate with which the protocol sends packets to the network using a congestion control window cwnd. A good congestion algorithm can fully utilize the bandwidth while avoiding over-driving the network and thereby creating packet losses. Since the introduction of the first widely used TCP congestion control algorithm TCP Reno in, many TCP congestion control algorithms have been proposed. On a high level, existing TCP congestion algorithms can be classified into three main categories based on the input to the control mechanism: namely Loss-based TCP, Delay-based TCP and Hybrid TCP.
Loss-based TCP includes: the original TCP Reno, TCP Bic, TCP CUBIC, High Speed TCP, Scalable TCP and so on. Among these Delay-based TCP variants, TCP Reno and TCP CUBIC are widely deployed Loss-based TCP as standard TCP algorithms and default TCP of Linux respectively. Using packet loss as the symptom for network congestion, Loss-based TCP reduces the value of cwnd when packet losses occur and increases the cwnd otherwise. A basic assumption in the design of Loss-based TCP congestion control is that packet losses are caused by over-driving the network only, which is no longer valid when the algorithm is applied to wireless networks. Random physical layer artifacts (e.g. multi-path, interferences) introduced packet losses that are typical for wireless networks will cause the congestion control algorithm to aggressively lower the cwnd. On the other hand, in a high BDP network, delay-based TCP requires a very low (in the order 10−7 or lower) random packet loss rate to fully utilize network capacity. This requirement is far from reality of network condition.
Delay-based TCP includes TCP Vegas and FAST TCP uses the queuing delay as the symptom for congestion. The queuing delay is defined as the difference between the RTT and the propagation delay, i.e. time actually required for a packet to be transmitted from the sender to the receiver. Delay-based TCP are more resilient to transient changes of network conditions such as random packet losses and are also suitable for high BDP networks. The down side of the approach on the other hand is that, because increase in round trip delay will not necessarily immediately lead to packet loss (due to buffers), when Delay-based TCP shares the same bottleneck with Loss-based TCP, between the time when delay starts to increase and packet loss occurs, the cwnd for the Delay-based TCP will decrease while that for the Loss-based TCP will not, leading to bandwidth “starvation” for the Delay-based sessions.
Hybrid TCP uses both packet loss and delay as inputs to the cwnd control mechanism and includes TCP variants for wireless environments such as Veno and TCP Westwood, as well as TCP variants for high speed links such as Compound TCP, TCP-Illinois, H-TCP and TCP-Fusion. Among these algorithms, Compound TCP has been widely deployed as the TCP congestion control algorithm in the Microsoft Windows Vista operating system while TCP-Fusion was used in the SUN Solaris 10. Although the performance of these TCP variants are good for the application scenarios they were originally designed for, for the emerging generation of high bandwidth wireless networks such as LTE and WiMAX, as well as for applications over heterogeneous networks combining segments of wired and wireless links, it becomes difficult for existing TCP congestion control algorithms to perform well.
Parallel TCP is yet another research area of TCP congestion control. The core idea of Parallel TCP is to create multiple actual or virtual TCP sessions that are controlled jointly so as to fully exploit network bandwidth. Parallel TCP in high speed wireless networks can achieve very good performance, parallel TCP sessions were used to optimize the user experience in multimedia streaming over wireless. In the system, it is required that the contexts of multiple TCP sessions be monitored, and the application layer software modified. In MulTCP, N virtual TCP sessions are utilized to simulate the behavior of multiple actual parallel TCP sessions, and can achieve very good performance when N is chosen properly, but may lead to either under-driving or over-driving the network if the value of N is not appropriate.
It is desired to have a TCP congestion control mechanism that can fully and fairly utilize the bandwidth in various networks, including high BDP networks as well as wireless networks.